一、概述

Android 是由 Google 主导的基于 Linux 的开源移动操作系统，由 Open Handset Alliance (OHA) 于 2007 年发布。其设计围绕四大核心原则：

• 开放性 — AOSP（Android Open Source Project）完全开源，Apache 2.0 许可
• 平等性 — 所有应用（含系统应用和第三方应用）地位平等，均可调用系统能力
• 无界性 — 应用间可相互调用和共享数据（通过 Intent / ContentProvider）
• 快速开发 — 丰富的 Java/Kotlin Framework API，显著降低开发门槛

Android 采用分层架构，自底向上分为：Linux Kernel → HAL → Native Libraries & ART → Java API Framework → System Apps。每一层对上层提供清晰的 API，对下层屏蔽实现细节。

版本演进关键节点

二、核心用例

从用户和开发者角度，Android 系统主要提供以下核心功能。

图 1：Android 系统核心用例图

Demo：通过 Intent 打开相机

// Kotlin: 启动系统相机拍照
val takePicture = Intent(MediaStore.ACTION_IMAGE_CAPTURE)
if (takePicture.resolveActivity(packageManager) != null) {
    startActivityForResult(takePicture, REQUEST_IMAGE_CAPTURE)
}

// 接收结果
override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
    if (requestCode == REQUEST_IMAGE_CAPTURE && resultCode == RESULT_OK) {
        val imageBitmap = data?.extras?.get("data") as Bitmap
        imageView.setImageBitmap(imageBitmap)
    }
}

三、系统启动流程

Android 设备上电到显示桌面（Launcher），经过如下阶段：

图 2：Android 系统启动活动图

四、App 启动流程

用户点击桌面图标到 Activity 显示，完整调用链如下。

图 3：App 启动时序图

五、Activity 生命周期

Activity 是 Android 应用最基本的表现组件。系统通过回调方法管理其从创建到销毁的完整生命周期，并在配置变化或内存紧张时重建。

图 4：Activity 生命周期状态机

Demo：生命周期回调

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        Log.d(TAG, "onCreate")
    }
    override fun onStart() { super.onStart(); Log.d(TAG, "onStart") }
    override fun onResume() { super.onResume(); Log.d(TAG, "onResume") }
    override fun onPause() { super.onPause(); Log.d(TAG, "onPause") }
    override fun onStop() { super.onStop(); Log.d(TAG, "onStop") }
    override fun onDestroy() { super.onDestroy(); Log.d(TAG, "onDestroy") }
    override fun onRestart() { super.onRestart(); Log.d(TAG, "onRestart") }
}

六、系统分层架构

Android 采用经典的 5 层架构，自下而上为：

图 5：Android 系统分层架构图

各层详细说明

七、Binder IPC 机制

Binder 是 Android 独有的进程间通信 (IPC) 机制，基于 OpenBinder 项目（Be Inc. 遗产）。它是整个 Framework 的通信总线：系统服务通过 Binder 向 App 暴露功能，App 间也可通过 Binder 通信。

图 6：Binder IPC 架构图（组件图）

Binder 关键对象：Binder Driver（内核驱动 /dev/binder，负责数据搬运，单次最大 1MB - 8KB 缓冲区开销）、ServiceManager（充当 DNS 角色，服务名为键）、Binder Proxy / Stub（Java/Kotlin 代理模式实现）。Binder 线程池上限 16 个，独立于应用主线程。

Demo：AIDL 定义远程服务

// IMusicPlayer.aidl
interface IMusicPlayer {
    void play(String uri);
    void pause();
    boolean isPlaying();
}

// 服务端实现
class MusicService : Service() {
    private val binder = object : IMusicPlayer.Stub() {
        override fun play(uri: String?) { /* 播放逻辑 */ }
        override fun pause() { /* 暂停逻辑 */ }
        override fun isPlaying(): Boolean = mediaPlayer.isPlaying
    }
    override fun onBind(intent: Intent?) = binder
}

// 客户端绑定
bindService(Intent(this, MusicService::class.java), serviceConnection, BIND_AUTO_CREATE)
val player = IMusicPlayer.Stub.asInterface(serviceConnection.service)

Binder vs 其他 IPC 对比

八、Android Runtime (ART)

ART 在 Android 5.0 中取代了 Dalvik 虚拟机，从 JIT (Just-In-Time) 转向 AOT (Ahead-Of-Time) 编译。Android 7.0 引入混合编译（Profile-guided JIT + AOT），平衡安装速度和运行时性能。

图 7：ART 编译流水线（状态机 + 活动图）

混合编译流程：

1. 安装时仅做轻量 verify（验证字节码合法性）
2. 首次运行时通过 JIT 解释 + 热点编译
3. 空闲时 dex2oat 根据 Profile 对热点代码做 AOT 编译为 .odex
4. 重启后优先加载 AOT 编译的机器码，未编译代码继续解释执行

ART vs Dalvik 对比

九、HAL 硬件抽象层

HAL 将硬件功能封装为标准接口，Framework 层通过 HAL 接口调用硬件而不需要关心厂商的实现差异。Android 8.0 引入 HIDL (HAL Interface Definition Language)，Android 11+ 迁移至 AIDL。

图 8：HAL 架构图（包图）

9.1 Project Treble（框架/厂商解耦）

Android 8.0 引入 Project Treble，将厂商实现（Vendor Implementation）与 Android 框架分离：

• VINTF (Vendor Interface) — 以 XML 声明 Framework 对 HAL 的版本要求，设备启动时校验兼容性
• HIDL/AIDL HAL — Framework 与 HAL 在不同进程运行，通过 Binder 通信，Framework 升级不再需要重新编译 HAL
• VNDK — Vendor Native Development Kit，厂商可用的稳定 NDK 子集

十、Framework 核心类

Android Framework 以系统服务为核心，最常见的 8 大核心服务：

图 9：Framework 核心类图

这些服务运行在 system_server 进程内，通过 Binder 向 App 进程暴露功能。每个服务都以 Manager 类的形式封装对外 API：

Demo：获取系统服务

// Kotlin: 通过 Context 获取系统服务
val am = getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager
val memInfo = ActivityManager.MemoryInfo()
am.getMemoryInfo(memInfo)
Log.d(TAG, "Available Memory: ${memInfo.availMem / 1024 / 1024} MB")

val wm = getSystemService(Context.WINDOW_SERVICE) as WindowManager
val display = wm.defaultDisplay
val metrics = DisplayMetrics()
display.getRealMetrics(metrics)
Log.d(TAG, "Screen: ${metrics.widthPixels}x${metrics.heightPixels} @ ${metrics.densityDpi}dpi")

十一、包图：源码结构

AOSP 源码主要包的依赖关系：

图 10：AOSP 源码包图（主要目录 + 依赖关系）

AOSP 关键源码目录

十二、安全模型

Android 安全基于纵深防御原则，多层防护互相叠加。

图 11：Android 安全纵深防御模型（部署图视角）

十三、总结

Android 通过分层架构（Kernel → HAL → Native → Framework → App）实现了硬件无关性与开发便捷性的平衡。其设计有三个关键特点：

• Binder 作为通信总线 — 所有系统服务通过 Binder 暴露，形成统一的 RPC 架构，一次拷贝零拷贝传输
• 组件作为基本单元 — Activity、Service、BroadcastReceiver、ContentProvider 四大组件构成应用骨架，通过 Intent 解耦组件间通信
• Zygote 孵化模型 — 父进程预加载 Framework 类和资源，fork 子进程时共享内存页（Copy-on-Write），显著加速 App 冷启动

从 Project Treble 的框架/厂商解耦到 Project Mainline 的模块化更新，从 Dalvik JIT 到 ART 混合编译，Android 持续演进其架构以适应多样化设备（手机、平板、手表、车机、TV、IoT）。